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Chapter 1 

Introduction 



1.1 Security Problems in C Standard Functions 

The functions standardized as part of ISO C 1999 and their addendums improved very httle the security 
options from the previously available library. 

The largest flaw remained that no function asked for the buffer size of destination buffers for any func- 
tion copying data into a user-supplied buffer. According to earlier research we performed |PMB] . we know 
that error condition handling was the first solution to security vulnerabilities, followed by precondition 
validation. The standard C functions typically perform little precondition validation and error handling, 
allowing for a wide range of security issues to be introduced in their use. 



For example: 



char *strncat (char *dest, const char *src, size_t n) ; 


does not null-terminate, can still 
overflow 


char *strtok(char * restrict si, const char * restrict s2) ; 


not reentrant 


size_t strlen(const char *s) ; 


can iterate in the memory up to 
an invalid page and cause a pro- 
gram crash 



This effort remained not enough, and many projects developed additional functions, namely: 



• OpenBSD strlcpy family |MdR99j 

• GNU C extensions fpro] 

• Microsoft strsafe.h and others |Cor05] 



1.2 Introducing ISO/IEC 

The International Standardization Organization (ISO) and the International Electrotechnical Commission 
(lEC) are standard-making bodies headquartered in Geneva (Switzerland) [ SecOSj . 
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Both organizations are constituted from an international membership, with local member organizations 
involved in standard-making activities as well. For example, we have the Standards Council of Canada, 
American National Standards Institute, Deutsches Institut fiir Normung, and Association frangaise de 
normalisation |ISO06bj . 

ISO and lEC collaborate closely on standards related to computer equipment and information tech- 
nologies. 

These organizations established a hierarchical structure under JTC 1 - Joint Technical Committee 
on Information Technology. JTC 1 is subdivided in 17 subcommittees, one of which (SC 22) deals with 
programming languages, with a working group for each programming languages |ISO06aj . 

The C language is normalized by ISO/IEC JTC 1/ SC 22/ WG 14. Its members include representatives 
from Microsoft, SEI/CMU, Cisco, Intel, etc |SC2] . The Computer Security Laboratory of CIISE, through 
Pr. Debbabi, is a member of this Working Group as Canadian representative with voting rights. 

1.3 ISO/IEC TR 24731 

In the ISO jargon, TR 24731 |WG106] is a Technical Report Type 2 |ISO05l USD] . which means that the 
document is not a standard, but a direction for future normalization. This specification is currently in the 
draft state. 

Titled "TR 24731: Safer C library functions", it defines 41 new library functions for memory copying, 
string handling (both for normal and wide character strings), time printing, sorting, searching etc. Another 
inovation it brings is a constraint handling architecture, forcing error handling when certain security-related 
preconditions are violated when the functions are called. It also specifies the null-termination of all strings 
manipulated through its function and introduces a new unsigned integer type that helps preventing integer 
overflows and underflows. It is currently implemented by Microsoft as part of their Visual Studio 2005 



Chapter 2 



Architecture 



In this chapter, we examine the architecture of our implementation of ISO/IEC TR 24731. We first 
introduce our architectural philosophy before informing the reader about the Siemens Four View Model, 
an architectural methodology for the conception of large-scale software systems. 

Afterwards, we examine each of the view, as architected for our library. 

Finally, we conclude with other software engineering matters that were of high importance in the 
development of our implementation. 

2.1 Principles and Philosophy 

The library specification imposes that the functions be in addition of other standard functions, in the same 
header files. However, we do not want our implementation to re-implement the standard C library, nor 
do we want to augment an existing implementation and be bound to a specific platform. The compromise 
solution is to organize the code to be using the low-level implementation of any existing C library, such as 
the one from GNU |gpj , FreeBSD or OpenBSD. 

In short, our principles are: 

Platform independence We target systems complying with the POSIX standard. 

Standards Compliance We will implement the library using features available only in ISO C99 and 
POSIX. 

C Library Independence We will architect in a way that prevents us being tied to the underlying C 
library. 

Realistic Compiler Indepedence A corollary of standards compliance, we will avoid compiler-specific 
macros and optimizations as possible. This means that the source code should be free of such 
dependencies, but that the build process may be bound to the compiler. 

Reasonable Efficiency We will architect and implement an efficient library, but will avoid advanced 
programming tricks that improve the efficiencv at the cost of maintainability and readability. 
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Simplicity And Maintainability We will target a simplistic and easy to maintain organization of the 
somxe. 

Architectural Consistency We will consistently implement our architectural approach. We could say 
that we will have a "template" approach. 

Separation of Concerns We will isolate separate concerns between modules and within modules to 
encourage reuse and code simplicity. 

Functional Grouping We will have functional coupling between within a module, meaning that func- 
tions will have a commonality of type, such as I/O, string manipulations, etc. 



2.2 Summary of Siemens Four View Model 

We decided to use the Siemens Four View Model for our architectural description, mostly due to previous 
experience using the technology. A detailed description with case studies can be found in |HNS00j . This 
methodology is introduced by scientists of Siemens Corporate Research and has been successfully applied to 



a variety of systems, many of which with real-time and embedded requirements. Please refer to Figure 2.1 
for an abstract presentation of the view. In the context of this project report, we inform the reader of the 
basic principles of each view. 



2.2.1 Conceptual View 

The conceptual view defines the conceptual components and their conceptual connectors, as well as their 
conceptual configuration. The architect, in this phase, must also specify resource budgets. 



2.2.2 Module View 

In the module view, the architect maps the conceptually-defined elements into modules and layers. The 
architect must then define the interface to the modules. 



2.2.3 Execution View 

In the execution view, the architect must define the runtime entities, the communication paths and the 
execution configuration. It essentially means the mapping of modules to threads and processes, and to 
define the inter-process communication mechanisms to be used. In the case of our library, there are no 
threads of execution per se, as such, this architectural step was skipped. 



2.2.4 Code View 

In the code view, the architect must define the source components, intermediate components and deploy- 
ment components, followed by the build procedure and configuration management. 
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Figure 2.1: High-Level Description of the Four Views |Cha] 

2.2.5 Conceptual View 
2.2.5.1 Conceptual Overview 

We divided our architecture in a few modules, isolating the core functionalities from each library and 
grouping functions per library. We also decided to use wrappers to a C library implementation. This 



overview can be seen in Figure Figure 2.2 



2.2.5.2 Configurations 

The only options in configuration relate to the wrappers to use for a specific C library. Since this is 
decided at compilation time and that only one is possible in any case, we decided not to further specify 
configurations. 



2.2.5.3 Protocols 

Because of the simplistic nature of the components (direction function calls) and that all components need 
to be re-entrant, we conclude that no protocols are necessary. 
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Figure 2.2: Conceptual Modules 
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2.2.5.4 Resource Budgeting 

We did not specify any resource budget for any components due to tlie lack of specific constraints. 



2.2.6 Module View 
2.2.6.1 Layering 

We divided our library between layers when we found significant redundancy for some operations. We 
decided to keep the memory copying for wide characters apart from the one without wide characters due 
to the risk of integer overflows that could result in faulty logic, and thus deserving a centralization of the 
functionality. 



The complete view of our layering is included in Figure Figure 2.3 



2.2.6.2 Interface Design 

The only interface that needed to be designed was related to the constraint validation. Please refer to the 



specification given in section Section 3.1 



2.3 Execution View 
2.3.1 Runtime Entities 

In the case of our library, there are no threads of execution per se, as the thread is provided by the calling 
program(s). 



2.3.2 Communication Paths 

It was resolved that the functions would all communicate through message passing. 



2.3.3 Execution Configuration 

Coherently with previous decisions, there are no specific execution configurations. 



2.4 Code View 

2.4.1 Source Components 

Each of stdio.h, stdlib.h, string. h, time.h, and wchar.h are mapped into a corresponding directory, 
as a module. The folder named test copies the previous structure, and contains test programs exclusively. 
The include directory contains the .h files to be included by external programs linking to the library. 
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Figure 2.3: Layering 
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|>iao_lec_tr_24731 
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Adapters to GNU C library 



Programmer interface for users 



Test programs 



Figure 2.4: Directory Tree 



10 



On Implementation of a Safer C Library, ISO/IEC TR 24731. 



The folder named adapters holds a sub-directory per C library implementation to adapt to, and each of 
those adapters mirror the base directory structure. Each interface function was implemented in a file with 
its name, to facilitate maintainability. Related functions are grouped in the file to which it is the most 
logically related. 

We established a naming convention for functions as follows: 
function The function's interface for the user. 

function_impl The function's implementation, used within the library. 

function_validate_preconditions The function's precondition validation component. 

function_component refactored sub-component of a function or common code within functions. 

2.4.2 Intermediate Components 

In order to facilitate the building process, we decided that each directory of functionality and adapters 
will assemble all intermediary ( . o) files into an archive ( . a). 

2.4.3 Deployment Components 

The only deployment component will be a .so file that includes our implementation and the underlying 
library. 

2.4.4 Make Process 

The build process is organized as a hierarchical organization of makefiles. Each makefile cross-reference 
the makefiles for its dependencies. The intermediary objects defined are the standard . o that are also 
grouped in an archive ( . a) . The testers are built separately from the library itself for efficiency and faster 
compilation. 

The make files are designed to adapt to both Linux and Windows / Cygwin platforms by detecting the 
presence of Cygwin and using different compiler options consequently. 

The documentation generation fits outside of the normal make process and is generated by the doxygen 
tool itself. 

2.4.5 Configuration Management 

We used Subversion (svn) |Tig| in order to manage the source code, makefile, and documentation revisions. 

2.5 Example for One Module 



In Figure 2.5 and Figure 2.6 we show the example of function call and source file dependencies for a 
function implementing vfprintf^. 
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contraint validator s 



_vfprintt_s_validale_preconditiQn s 



m e m or y_z er o_fi I l_r an g e 



validate n format 



validate s formal 



Figure 2.5: Call dependencies for function vfprintf_s 



stdio/vfprintf_s,c 




Figure 2.6: File dependencies for function vfprintf_s 



2.6 Iterations 



In order to efficiently reach our architectural goal, we divided the final objectives of the project in the 
following steps: 



1. Implementation of the body, without precondition validations 

2. Implementation of precondition validation and integration 

3. Validation of compliance for all testable cases 

4. Implementation of adapters to a C library 

5. Redefinition of insecure function calls to our function calls 



2.7 Coding Standards 

In order to produce high-quality code, we decided to normalize on the OpenBSD style. We also decided to 
use Doxygen [vHj source code documentation style for its completeness and the automated tool support. 



Chapter 3 

Implementation 



This chapter gives concrete implementation details for the constraint handling API and examples of its 
usage. An excessive amount of work was done to have a decent precondition validation and this chapter 
mostly focuses on the API aspect of this implementatition. A particular achievement was to fully enable 
parsing and restraining of %s and %n modifiers with the flex-based scanner. 

3.1 Run-time Constraint Handling API 

For precondition validation we deviced an API to encasulate run-time constraint check and violation 
information and an appropriate currently registered constraint handler. Later on this was abstracted with 
inline function calls reducing the clutter for the libc_s programmers such as ourselves and for those who 
might maintain it after us. 

The standard defines this type to allow custom constraint handlers in stdlib.h: 

typedef void (* constraint_handler_t )( const char* restrict msg , void* restrict ptr , errno_t error); 

constraint_handler_t set_constraint_handler_s ( constraiiit_handler_t handler) ; 

void abort_handler_s ( const char * restrict msg, void * restrict ptr, errno_t error); 

void ignore_handler_s ( const char * restrict msg, void * restrict ptr, errno_t error); 

Listing 3.1: Standard API for Constraint Handling 

In our implementation we mark abort_handler_s as the default handler for all contraint violations. 
That means, after erroring out, the handler calls exit(O) and the application build around libc_s termi- 
nates. 



3.2 Constraint Violation Information Encapsulation API 

This is the capsule enclosing the error information we defined. The structure depicts some meta information 
about a paramater and its value. An instance of this structure is created for each input parameter to be 
validated. 
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LisLing 3.2: ^ 


■5yno]")sys: paraiii_validation_status_t 


#include "stdlib_impleinentation.h" 


typedef struct _param_validation_status_t 


{ 






e_errcheck errtype ; 




const 


void* value ; 




const 


void* pairvalue ; 




const 


void* result ; 




const 


char * restrict 


f unction_naiiie ; 


const 


char * restrict 


param_name ; 


const 


char * restrict 


pair_param_naine ; 


bool 


error_present ; 




} param_validation_status_t ; 




Some helper 


data structures allow 


us to describe more complex types. The parain_raiige_t struct 



allows specifying the range for a domain value. A reference to the instance of this struct is passed in 
the parain_validation_status_t .pairvalue field. The object_range_t struct is supposed to contain the 

data describing a memory objec with its starting address and length. The purpose of this is to help with 
validation of ranged objects that they do not overlap in memory. The implementor of the library should 
provide the two intances of this struct as references in value and pairvalue of the two ranged objects. 
Which object reference goes to where is unimportant as the implementation takes care of figuring out the 
object precedence. 



Listing 3.3: Synopsys: param_range_t 

typedef struct _param_range_t 
{ 

size_t min; 
size_t max; 
> param_range_t ; 



Listing 3.4: Synopsys: object_range_t 

typedef struct _ob j ect_range_t 
{ 

const void* restrict object_ptr; 
size_t ob j ect_length ; 
} ob j ect_range_t ; 
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3.3 Constraint Enumeration and Validator 



The enumeration in Listing 3.5 defines most common error types to check for and report. These correspond 



to the index for the human readable error messages. 



typedef enum 








{ 










E_ 


.NOERRQR = 0, 








E_ 


_NULL_PARAMETER_NQT_ALLOWED = 


1 , 






E_ 


_PARAMETER_OUT_OF_RANGE = 2, 








E_ 


.ENVIRONMENT AL_LIMIT_NOT_MET 


= 3 






E_ 


_INVALID_FORMAT_PARAMETER_S = 


4 , 


/* 


Xs */ 


E_ 


_INVALID_FORMAT_PARAMETER_N = 


5 , 


/* 


Xn */ 


E_ 


_RSIZE_MAX_EXCEEDED = 6, 








E_ 


.NOT_ZERO = 7, 








E_ 


.QBJECTS_OVERLAP = 8, 








E_ 


.NQT_IMPLEMENTED = 9, 








E_ 


.TOKEN_END_NOT_FOUND = 10 








} e_errcheck ; 









Listing 3.5: Enumeration of most common error types to check for. 
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errno.t __error_out (param_validation_status_t * restrict status); 

errno_t __contraint_validator_s (param_validation_status_t * restrict status); 

erriio_t 

__constraint_validator_obj ect_overlap ( const char * restrict f unction_name , const char * restrict 
parameterNames , const void * restrict ob j ect IStart , const size_t objectlSize, const void * 
restrict ob j ect2Start , const size_t ob j ect2Size ) ; 

errno_t 

__constraint_validator_value_inrange ( const char * restrict f unction_name , const char * restrict 

parameterName , const size_t value, const size_t lowerBound , const size.t upperBound) ; 
errno_t 

__constraint_validator_not_null ( const char * restrict function_name , const char * restrict 

parameter_name , const void * restrict value_ptr); 
errno_t 

__constraint_validator_not_null_args ( const char * restrict function_name , const char * restrict 

parameter_name , const char * restrict format, const va_list args); 
errno_t 

__ const raint_val idator_s_f ormat ( const char * restrict function_name , const char * restrict 

parameter_naine , const char * restrict format, const va_list args); 
errno_t 

__cons traint_val idat or _n_f ormat ( const char * restrict f unction_name , const char * restrict 
parameter_name , const char * restrict format, const va_list args); 

errno_t 

__constraint_validator_not_2ero ( const char * restrict f unction_name , const char * restrict 
parameter_name , const size_t value) ; 

errno_t 

__constraint_validator_rsize_liniit ( const char * restrict function_name , const char * restrict 
parameter_name , const rsize_t value); 

void 

__report_constraint_violation_end_of _token_not_present ( const char * restrict f unction_name , const 
char * restrict parameter_name ) ; 



Listing 3.6: Constraint Validator API 
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3.4 Constraint Handling Example 



Our implementation of the API (in Listing 3.6) does something similar to the code snippet presented in 
Listing [XTj 



param_validatioii_status_t format_string_validation ; 

memory_zero_fill_raiige (&forinat_string_validation , sizeof (parani_validatioii_status_t)) 

format. string. validation . errtype = E_INVALID_FORMAT_PARAMETER_S ; 
f ormat _ St ring_val idat ion . value = format; 
f ormat _ St r ing_ val idat ion . pairvalue = &arg; 

f ormat _ St r ing_val idat ion . par am_name = "format/arg null 7,s" ; 
f ormat _ St ring_ val idat ion . funct ion_name = " vf print f _ s " ; 

error = cont raint _ val idat or _ s (& f ormat _ str ing_ val idat i on ) ; 

if(error != OK) 
{ 

errno = error ; 
return error ; 

} 



Listing 3.7: Validation Code 



Chapter 4 



Results 



This chapter summarizes the result achieved as of this writing. This includes implemented API to this 
point as well as some concrete results demonstraiting correctness of implementation. 



4.1 Implemented API 

This is the summary of the implemented API from the library and our internal constraint handling. We 
summarized the functions and data types added in ISO/IEC TR 24731 in this section for the sake of 
reference. 



4.1.1 Library 
4.1.1.1 Data Types 

Added the following data types: rsize_t, errno_t, constraint Jiaiidler_t that were necessary to add. 



4.1.1.2 Functions 



The functions in Listing 4.1 were to the large extend implemented by our team as of this writing. Likewise, 



Listing 4.2 lists API not yet addressed. Finally, Listing [4^ lists API implemented half-way through. 



4.1.2 Private Constraint Handling API 
4.1.2.1 Data Types 

Added the following data types: parain_validation_status_t, param_range_t, object_range_t that were 
necessary to add. 
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int f printf _s (FILE * restrict stream, const char * restrict format, ...); 
int f s canf _ s ( FILE * restrict stream, const char * restrict format, ...); 
int printf _s ( const char * restrict format, ...); 
int scanf_s ( const char * restrict format, ...); 

int snprintf _s ( char * restrict s, rsize_t n, const char * restrict format, ...); 

int sprintf _s ( char * restrict s, rsize_t n, const char * restrict format, ...); 

int sscanf_s ( const char * restrict s, const char * restrict format, ...); 

int vf printf _s (FILE * restrict stream, const char * restrict format, va_list arg) ; 

int vf s canf _s ( FILE * restrict stream, const char * restrict format, va_list arg); 

int vprintf_s ( const char * restrict format, va_list arg); 

int vs canf _s ( const char * restrict format, va_list arg); 

int vsnprintf _s ( char * restrict s, rsize_t n, const char * restrict format, va_list arg); 

int vsprintf _s ( char * restrict s, rsize_t n, const char * restrict format, va_list arg); 

int vsscanf_s ( const char * restrict s, const char * restrict format, va_list arg); 

constraint _handler_t set_constraint_handler_s ( constraint_handler_t handler) ; 

void abort_handler_s ( const char * restrict msg , void * restrict ptr , errno_t error); 

void ignore_handler _s ( const char * restrict msg, void * restrict ptr, errno_t error); 

errno_t wctomb_s(int * restrict status, char * restrict s, rsize_t smax , wchar_t wc); 

errno_t mbstowcs_s ( size_t * restrict retval , wchar_t * restrict dst , rsize_t dstmax , const char * 

restrict src , rsize_t len) ; 
errno_t wcstombs_s ( size_t * restrict retval, char * restrict dst, rsize_t dstmax, const wchar_t * 

restrict src , rsize_t len) ; 
errno_t memcpy.s ( void * restrict si, rsize.t slmax, const void * restrict s2 , rsize.t n) ; 
errno_t memmove_s ( void *sl, rsize_t slmax, const void *s2, rsize_t n) ; 
errno_t strcpy_s ( char * restrict si, rsize_t slmax, const char * restrict s2); 
errno_t strncpy_s ( char * restrict si, rsize_t slmax, const char * restrict s2 , rsize_t n) ; 
errno_t strcat_s ( char * restrict si, rsize_t slmax, const char * restrict s2); 
errno_t strncat_s ( char * restrict si, rsize_t slmax, const char * restrict s2 , rsize_t n) ; 
char * strtok_s ( char * restrict si, rsize_t * restrict slmax, const char * restrict s2 , char ** 

restrict ptr) ; 

int f wprintf _s (FILE * restrict stream, const wchar_t * restrict format, ...); 

int f wscanf _s (FILE * restrict stream, const wchar_t * restrict format, ...); 

int snwpr int f _s ( wchar _t * restrict s, rsize_t n, const wchar_t * restrict format, ...); 

int swprintf _s (wchar.t * restrict s, rsize.t n, const wchar.t * restrict format, ...); 

int swscanf_s ( const wchar.t * restrict s, const wchar_t * restrict format, ...); 

int vf wprintf _s (FILE * restrict stream, const wchar_t * restrict format, va_list arg); 

int vf wscanf _s (FILE * restrict stream, const wchar_t * restrict format, va_list arg); 

int vsnwprintf _s (wchar_t * restrict s, rsize_t n, const wchar_t * restrict format, va_list arg); 

int vswprintf _s (wchar_t * restrict s, rsize_t n, const wchar_t * restrict format, va_list arg); 

int vswscanf_s ( const wchar_t * restrict s, const wchar_t * restrict format, va_list arg); 

int vwprintf _s ( const wchar_t * restrict format, va_list arg); 

int vwscanf_s ( const wchar_t * restrict format, va_list arg); 

int wprintf _s ( const wchar.t * restrict format, ...); 

int ws canf _s ( const wchar_t * restrict format, ...); 



Listing 4.1: Implemented Safer C Library API 
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char *gets_s(char *s, rsize_t n) ; 

errno_t getenv_s ( size_t * restrict len , char * restrict value, rsize_t maxsize , const char * 
restrict name); 

void *bsearch_s ( const void *key , const void *base , rsize_t nmemb , rsize_t size, int (*compar)( 

const void *k, const void *y, void *context), void *context); 
errno_t qsort_s(void *base , rsize_t nmemb, rsize_t size, int (* compar )( const void *x, const void * 

y, void *context), void *context); 
errno_t str error_s ( char *s , rsize_t maxsize, errno_t errnum) ; 
size_t strerrorlen_s ( errno_t errnum); 
size_t strnlen_s ( const char *s, size_t maxsize); 

errno_t asctime_s ( char *s, rsize_t maxsize, const struct tm *timeptr) ; 
errno_t ctime_s(char *s, rsize_t maxsize, const time_t *timer) ; 

struct tm *gmtime_s ( const time_t * restrict timer, struct tm * restrict result); 

struct tm * localt ime_s ( const time_t * restrict timer, struct tm * restrict result); 

errno_t wcscpy_s (wchar_t * restrict si, rsize_t slmax , const wchar_t * restrict s2); 

errno_t wc sncpy _ s ( wchar _ t * restrict si, rsize_t slmax, const wchar_t * restrict s2 , rsize_t n) ; 

errno_t wmemcpy_s (wchar_t * restrict si, rsize_t slmax, const wchar_t * restrict s2 , rsize_t n) ; 

errno.t wmemmove.s ( wchar _t *sl , rsize.t slmax, const wchar.t *s2, rsize.t n) ; 

errno.t wcscat.s (wchar_t * restrict si, rsize_t slmax, const wchar_t * restrict s2) ; 

errno.t wcsncat.s (wchar.t * restrict si, rsize_t slmax, const wchar.t * restrict s2 , rsize_t n) ; 

wchar_t *wcstok_s (wchar_t * restrict si, rsize_t * restrict slmax, const wchar_t * restrict s2 , 

wchar.t ** restrict ptr); 
size_t wcsnlen_s ( const wchar_t *s, size_t maxsize); 

errno_t wcrtomb_s ( size_t * restrict retval , char * restrict s, rsize_t smax , wchar_t wc , mbstate_t 
* restrict ps); 

errno.t mbsrtowcs_s ( size.t * restrict retval, wchar_t * restrict dst , rsize_t dstmax , const char 

** restrict src , rsize_t len, mbstate.t * restrict ps); 
errno_t wcsrtombs_s ( size_t * restrict retval, char * restrict dst, rsize_t dstmax, const wchar_t 

♦♦restrict src, rsize_t len, mbstate.t * restrict ps) ; 

Listing 4.2: Not Implemented Safer C Library API 



errno.t tmpf ile_s (FILE * restrict * restrict streamptr); 
errno_t tmpnam.s ( char *s, rsize.t maxsize); 

errno_t fopen_s(FILE * restrict * restrict streamptr, const char * restrict filename, const char * 

restrict mode) ; 

errno_t f reopen_s (FILE * restrict * restrict newstreamptr , const char * restrict filename, const 
char * restrict mode , FILE * restrict stream) ; 

Listing 4.3: Partially Implemented Safer C Library API 
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errno_t __validate_ii_f ormat ( const char * restrict format, va_list args); 
errno.t __validate_s_f ormat ( const char * restrict format, va_list args); 
errno.t __validate_sn_f ormat ( const char * restrict format, va_list arg) ; 

/* constraint validator ; constraint_validator_s . c */ 

errno_t __error_out (bool errf lag , par am_ val idat i on_ s t atus _t * restrict status); 
errno_t __constraint_validator_s (param_validation_status_t * restrict status); 

errno_t 

__constraint_validator_obj ect_overlap ( const char * restrict function_name , const char * restrict 
parameterNames , const void * restrict ob j ect IStart , const size_t objectlSize, const void * 
restrict ob j ect2Start , const size_t ob j ect2Size ) ; 

errno_t 

__constraint_validator_value_inrange ( const char * restrict function_name , const char * restrict 
parameterHame , const size_t value, const size_t lowerBound , const size.t upperBound) ; 

errno_t 

__constraint_validator_not_null ( const char * restrict function_name , const char * restrict 
parameter_name , const void * restrict value.ptr); 

errno_t 

..constraint. val idat or _s_f ormat ( const char * restrict f unction.name , const char * restrict 
parameter.name , const char * restrict format, const va.list args); 

errno.t 

__constraint_validator_n_f ormat ( const char * restrict function_name , const char * restrict 
parameter_name , const char * restrict format, const va.list args); 

errno_t 

__constraint_validator_not_zero ( const char * restrict f unction_name , const char * restrict 
parameter_name , const size_t value) ; 

errno_t 

..constraint .validator _rs ize_limit ( const char * restrict function.name , const char * restrict 
parameter.name , const rsize.t value); 

void 

__report_constraint_violation_end_of _token_not_present ( const char * restrict f unction_name , const 
char * restrict parameter _name ) ; 

Listing 4.4: Implemented Constraint Handling API 



errno_t __validate_args_not_null ( const char * restrict format, va_list args); 

errno_t 

__constraint_validator_not_null_args ( const char * restrict function_name , const char * restrict 
parameter_name , const char * restrict format, const va.list args); 



Listing 4.5: Not Implemented Constraint Handling API 



On Implementation of a Safer C Library, ISO/IEC TR 24731. 21 
4.1.2.2 Functions 



The functions in Listing 4.4 were to the large extend implemented by our team as of this writing. Likewise, 



Listing 4.5 lists API not yet addressed. 



4.2 Constraint Handling In Action — stdio 



Test code is in Listing 4.6 



* Sloppy Programming Test Cases 

*/ 

#define __STDC_WANT_LIB_EXT1__ 1 
#include "stdio. h" 
#include "stdlib.h" 

#iiiclude <uiiistd.h> 
#include <string.h> 

int 

mainCint argc , char** argv) 
{ 

int valid = 1; 

set_constraint_handler_s (ignore_handler_s) ; 

if(argc > 1) 
{ 

printf (" Sloppy programming zone: [[7oS]]\n", argv[l]); 
printf_s (argv [1] ) ; 
printf ( " \n\n" ) ; 

} 

printf _s (" valid s = ['/,s]\n", "valid"); 
printf_s(" valid nl = [7.'/o'/.'/.n] \n\n" , fevalid); 
printf _s (" invalid n2 = ['/////.n] \n\n" , fevalid); 
printf_s(" valid n3 = ['/."/.n] \n\n" , fevalid) ; 
printf _s (" invalid n4 = [7,n]\n\n", fcvalid); 

printf _s (" invalid s = [y.s]\n", NULL); 
printf _s (" invalid n = [VonlXnXn", &argc); 

printf (" return value for '/,'/,n : [y,d]\n", pr int f _s ( " "/.nXn " , &argc)): 
printf (" return value for '/,'/, s : [y,d]\n", pr int f _s ( " 7,5 \n " , NULL)); 



return 0; 



} 

/* EOF */ 



Listing 4.6: Example of a Test Program for stdio to test and reject invalid %s and %n cases. 
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Output is in Listing 4.7 



bash-2.05b$ t est / stdio / test y.n 
Sloppy progr ammiiig zone; [ [yoii] ] 

printf_s(): invalid format parameter C/.n is disallowed) : format/args y,n 



valid s = [y.s] 

valid s = [valid] 

valid nl = [n] 

valid nl = [XXn] 



invalid n2 
valid n3 



[printf _s () 
[n] 



invalid format parameter (Zn is disallowed) : format/args y,n 



valid n3 = [y.n] 



invalid n4 = [printf _s() : invalid format parameter (Zn is disallowed) : format/args Zn 
printf_s(): invalid format parameter (NULL argument for '/,s) : format/args null '/,s 
invalid n = [printf_s(): invalid format parameter (y,n is disallowed) : format/args y.n 
printf_s(): invalid format parameter (y.n is disallowed) : format/args y.n 
return value for y.n: [22] 

printf_s(): invalid format parameter (NULL argument for y.s) : format/args null y.s 
return value for y.s: [22] 
bash -2 . 05b$ 



Listing 4.7: Output 



4.3 Constraint Handling In Action — string 

Test code is in Listing 4.8 
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■ft A a -f -i -n £1 QTDP TJATVTT TTR T7YT1 1 




#include "string.h" 




#include <errno .h> 




#include <stdio .h> 




#include <striiig.h> 
















rha-r hiiffpT9 [1094.1 • 




• 

s 6 1 _ c ons t r SL int _lia.iidl 6 r _ s ( igiiore_ha.iidl63r_s ) j 




/ * F di XuT €■ tests */ 




pniitf("strcpy_s fELilux*6 t6sti\t")j 




a-t y /^TttT c/'Vin-f-FciT-l 100A MTTTT^- 

BTiicpy_svDu.iieiri , luz'i, imulLi^ , 
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i3Uxii(..py_oVLju.xj.cxx ) » uuxxt?x^ ^ ovj j ^ 




ppin'tf C"stnicELt_s f&ilur© 'tss't ;\"t") j 




strcat_s (buf f erl , -1, buffer2); 




printf("striicat_s failure test:\t"); 
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printf ("nieiiiiiiove_s failure test :\t") ; 




memmove_s (buf f er 1 , 1023, NULL, 1024); 




/ * 11 U f III It V^GItiObUlt tCOl/O*/ 




STixcpy_sv.Durieri, i\jz*± ^ i^&si^ ST^nng j f 




printf ("strcpy_s; \ii", buff6rl)j 




STixiicpy_sv.Diiiieiz ^ lu^ft, uuiieri ^ luzft^ , 












priin;!^. SLxCax_s. /bS \ii , Duiieri^, 




printf (" strnlen_s (buf f erl) : '/.u \n", strlength) ; 




size_t errlen = str err or len_ s ( EINVAL) ; 




printf (" strerrorlen.s (EINVAL) : /.uXn" , errlen); 




strerror.s (buf f er2 , 1014, EINVAL); 




printf ('"/.sNn" , buffer2); 




rsize_t 1= striileii_s (buf f erl , 100) ; 




char * strktokresult = NULL; 




char * token = strtok.s (buf f erl , &1 , " ", ftstrktokresult ) ; 


printf (" strtok_s token: °/,s, remaining length: %u , 


remaining substring: °/,s\n" , token, 1, 


strktokresult) ; 




token = strtok.s (NULL , &1 , "gt", festrktokresult ) ; 


/*Should be found*/ 


/*Move printfs to a real test file*/ 




size_t s = strnlen.s (" 12345 " , 10); 




pr intf ( " s ize : '/.uXn" , s) ; 

} 





Listing 4.8: Example of a Test Program for string to test and reject invalid cases. 
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Output is in Listing 4.9 



has invalid NULL pointer argument : s2 
failure test: strcat_s () : rsize_t value exceeds RSIZE_MAX 



has invalid NULL pointer argument : si 
two data structures overlap in memory ; 
rsize_t value exceeds RSIZE_MAX : n 
has invalid NULL pointer argument : s2 



si and s2 



bash-2.05b$ t est / string / test 
strcpy_s failure test: strcpy_s() 
strncpy_s failure test: strncat. 
s Imax 

strncat_s failure test: strncat_s () 
strncat_s failure test: strncat_s () 
memcpy_s failure test: memcpy_s(): 
memmove_s failure test: memmove_s () 
strcpy_s : test string 
strncpy_s : test string 
strcat_s : test stringtest string 
strncat_s : test stringtest stringtest string 
memmove_s : test stringtest stringtest string 
memcpy_s : test stringtest stringtest string 
St rnlen_s ( buf f er 1 ) : 33 
strerrorlen_s (EINVAL) : 
test string 

strtok_s token: test, remaining length: 28, remaining substring: stringtest stringtest string 
strtok_s token: strin , remaining length: 21, remaining substring: est stringtest string 
strtok_s() : token end not found within defined bounds : *ptr 

strtok_s token: est stringtest string, remaining length: 0, remaining substring: 
size: 5 
bash -2 . 05b$ 



Listing 4.9: Output 



Chapter 5 



Conclusions 

Here were briefly address the following topics: 

• Difficulties 

• Limitations 

• Acknowledgments 

• Future Work 

5.1 Summary of the Difficulties 

1. Parsing/processing of varargs and %n in particular 

2. Deciding on default values 

3. Implementing strtok_s and its wide character equivalent 

5.2 Limitations So Far 

• Incomplete implementation (of approx. 45%) of the entire API 

• Lack of thorough testing for all the implemented API 

5.3 Acknowledgments 

• Dr. Prabir Bhattacharya 

• Dr. Mourad Debbabi 

• ISO 

• Open Source Community and the GLIBC Team jgpj 
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5.4 Future Work 

This project, being a derivative of the standard C hbrary, will see a major effort put into the testing of 
the library. Furthermore, a large part of the project (transforming the obsolete calls to wrappers to the 
newer ones) makes the assumption that the buffer free size is easily obtainable, an assumption which may 
not necessarily hold true in all circumstances. As such, it is possible that we will have to develop novel 
algorithms to ensure that this portability is possible, or it may also be that this portability is not 100% 
attainable. Furthermore, we will need to investigate good potential software for performance and security 
testing of our improved solution. Thus, we will focus on: 

• Completion of implementation, 

• Addition more comprehensive test cases by the developers and the OSS community, 

• Application for EAL5, 

• Inclusion into the Linux kernel as a standard. 
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